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TITLE 

METHOD FOR COMMONLY CONTROLLING DEVICE DRIVERS 

CLAIM OF PRIORITY 
[0001] This application makes reference to, incorporates the same herein, and claims all benefits 
accruing under 35 U.S.C. §119 from an application for COMMON CONTROL IMPLEMENT 
METHOD FOR DEVICE DRIVER earlier filed in the Korean Industrial Property Office on 8 August 
2002 and there duly assigned Serial No. 2002-46757. 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0002J The present invention relates to a communication system, and more particularly to a 
method for commonly controlling device drivers of a hardware chip level. 

Description of the Related Art 
[0003] Currently, manufacturers of higher-order applications and lower-order device drivers 
develop their products independently of one another. Presently, different vendors provide a large 
number of device drivers. This means that the lack of communication between the manufacturers 
of the higher-order applications and the lower-order device drivers can become serious. 
Conventionally, APIs (Application Program Interfaces) are made on the basis of individual unique 
respective standards of the higher-order applications and the lower-order device drivers. 
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Accordingly, the higher-order applications and the lower-order device drivers can be made to 
conform to the standards of each other. 

[0004] Where the device driver cannot meet the requirements of the higher-order applications, 
there is a problem in that a code or structure affecting the higher-order applications should be 
corrected. At this time, the higher-order applications and the device driver should be re-verified. 

[0005] If a specific portion is changed where a first device is changed to a second device in 
relation to a common application or two applications use a common device driver, the higher-order 
applications and the device drivers should be re-verified. The re-verification requirement can 
adversely affect the development of products and reduce competitiveness of the product because of 
the increased time needed for the product development. 

SUMMARY OF THE INVENTION 
[0006] Therefore, the present invention has been made in view of the above and other problems, 
and it is an object of the present invention to provide a method capable of independently and 
commonly employing a higher-order application hierarchy and a lower-order device driver by 
arranging a DIA (Device Independent Access) hierarchy as an intermediate hierarchy between the 
higher-order application hierarchy and the lower-order device driver for the sake of establishing a 
mutual interface in a communication system. 
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[0007] It is another object of the present invention to provide a method capable of independently 
and commonly employing a lower-order device driver hierarchy in a communication system. 

[0008J It is yet another object of the present invention to provide a method capable of 
independently and commonly employing a higher-order application hierarchy in a communication 
system. 

[0009] In accordance with an aspect of the present invention, the above and other objects can be 
accomplished by the provision of a method for commonly controlling device drivers, including: 
arranging a DIA (Device Independent Access) hierarchy between an application hierarchy and a 
device driver hierarchy and applying a standardized rule of the DIA hierarchy to the application 
hierarchy and the device driver hierarchy; and allowing the application hierarchy and the device 
driver hierarchy to access the device driver hierarchy and the application hierarchy through the 
standardized rule of the DIA hierarchy, respectively. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] A more complete appreciation of the invention, and many of the attendant advantages 
thereof, will be readily apparent as the same becomes better understood by reference to the following 
detailed description when considered in conjunction with the accompanying drawings in which like 
reference symbols indicate the same or similar components, wherein: 

[0011] Fig. 1 is a view illustrating a case where a device A is changed to a device B in relation to 
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a common application; 

[00121 Fig. 2 is a view illustrating a case where two applications use a common device driver; 
[0013] Fig. 3 is a view illustrating a concept of commonly controlling device drivers in accordance 
with an embodiment of the present invention; 

[0014] Fig. 4 is a view illustrating an access for device driver control commonization; 

[00151 Fig- 5 is a view illustrating a connection structure of a DCB (Device Control Block) after 

an API (Application Program Interface) "DiaJhiitDevice" is called for device initialization; 

[00161 Fig. 6 is a view illustrating a final DCB in a level 1 initialization stage; 

[00171 Fig- 7 is a view illustrating a connection structure of a DCB when an HDLC (High-level 

Data Link Control) device having four ports corresponding to a level 2 is initialized; 

[0018] Fig. 8 is a view illustrating a connection structure of a DCB when a channel is initialized; 

[0019] Fig. 9 is a view illustrating a structure of an event table; 

[0020] Fig. 10 is a view illustrating a case where a device driver is changed (or replaced) in 
accordance with an embodiment of the present invention; 

[0021] Fig. 1 1 is a view illustrating a case where a higher-order application (program) is changed 
in a conventional art; 

[0022] Fig. 12 is a view illustrating a case where a lower-order device is changed in a 
conventional art; 

[0023] Fig. 1 3 is a view illustrating a case where a higher-order application (program) is changed 
in accordance with an embodiment of the present invention; 

[0024] Fig. 14 is a view illustrating a case where a lower-order device is changed in accordance 
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with an embodiment of the present invention; and 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0025] Turning now to the drawings, Fig. 1 illustrates a case where a device A is changed to a 
device B in relation to a common application. Fig. 2 illustrates a case where two applications use 
a common device driver. 

[0026] Referring to Fig. 1 , when the device A is changed to the device B in relation to a common 
application 2 as a higher-order application 2, a device-A driver 4 is also changed to a device-B driver 
6, wherein the device-A and device-B drivers 4 and 6 are lower-order device drivers. If so, APIs 
have different characteristics associated with the devices A and B. Accordingly, the higher-order 
application 2 should be also changed according to the changed device and device driver. When the 
device driver is changed, all APIs associated with the changed lower-order device driver should be 
newly verified. In other words, it should be verified whether the APIs appropriately operate on the 
basis of the changed device driver. Further, it should be checked whether all higher-order 
applications associated with the changed lower-order device driver affect others. 

[0027] Next, referring to Fig. 2, a higher-order application-A 1 0 and a higher-order application-B 
1 2 use a common device driver 1 4. The higher-order applications- A and B 1 0 and 1 2 need different 
formats from the device driver 14. For example, the higher-order application-A 10 needs two 
formats A-l and A-2 provided from the device driver 14. Otherwise, the higher-order application-B 
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12 needs three formats B-l, B-2 and B-3 provided from the device driver 14. This case occurs 
because a format agreement between the applications has not been agreed upon. Accordingly, the 
device driver 1 4 should change formats in response to different requirements from the higher-order 
applications- A and B 10 and 12 and therefore the APIs should be changed and added. Where the 
device driver cannot meet the requirements of the higher-order applications, there is a problem in 
that a code or structure affecting the higher-order applications should be corrected. At this time, the 
higher-order applications and the device driver should be re-verified. 

[0028] As described in connection with Figs. 1 and 2, if a specific portion is changed where the ■ 
device A is changed to the device B in relation to the common application or the two applications 
use the common device driver, the higher-order applications and the device drivers should be 
re- verified. The re- verification requirement can adversely affect the development of products and 
reduce competitiveness of the product because of the increased time needed for the product 
development. 

[0029] The present invention prevents a higher-order application hierarchy and a lower-order 
device driver hierarchy from directly accessing each other by arranging a DIA (Device Independent 
Access) hierarchy between the higher-order application hierarchy and the lower-order device driver 
hierarchy in a communication system. Accordingly, the higher-order application hierarchy and the 
lower-order device driver hierarchy can access the lower-order device driver hierarchy and the 
higher-order application hierarchy via the DIA on the basis of the DIA's standardized rule, 
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respectively. Because the higher-order application hierarchy and the lower-order device driver 
hierarchy accesses the lower-order device driver hierarchy and the higher-order application hierarchy 
on the basis of the DIA's standardized rule, respectively, a period of time required for the 
development of products, and costs of product development can be reduced, and efficiency of 
product development can be improved. 

[0030] Now, preferred embodiments of the present invention will be described in detail with 
reference to the annexed drawings. In the following description, a detailed description of known 
functions and configurations incorporated herein will be omitted when it may make the subject 
matter of the present invention rather unclear. 

[0031] Fig. 3 is a view illustrating a concept of commonly controlling device drivers in accordance 
with an embodiment of the present invention. Referring to Fig, 3, a DIA (Device Independent 
Access) hierarchy 22 is arranged between a higher-order application 20 and device drivers 24 and 
26 in a communication system in accordance with the embodiment of the present invention. The 
higher-order application 20 accesses the device drivers 24 and 26 via the DIA hierarchy 22 on the 
basis of a standardized rule of the DIA hierarchy 22. Similarly, the device drivers 24 and 26 access 
the higher-order application 20 via the DIA hierarchy 22 on the basis of the standardized rule of the 
DIA hierarchy 22. This will be described in detail with reference to Fig. 4. 



[0032] 



Fig. 4 is a view illustrating an access for device driver control commonization. Referring 
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to Fig. 4, when the higher-order application 20 requests the DIA hierarchy 22 to provide information 
associated with an LOS (Loss Of Signal) state based on a standardized common format, the DIA 
hierarchy 22 converts the request into a device-A local format and then requests a device-A driver 
24 to provide the LOS state information. Accordingly, the device-A driver 24 provides the LOS 
state information based on the device-A local format to the DIA hierarchy 22. The DIA hierarchy 
22 converts the LOS state information based on the device-A local format into the standardized 
common format and then provides the LOS state information based on the standardized common 
format to the high-order application 20. On the other hand, if a device A is changed to a device B, 
a device-A driver is also changed to a device-B driver. The higher-order application 20 requests the 
DIA hierarchy 22 to provide the LOS state information based on the standardized common format . 
irrespective of the changed device. Further, the DIA hierarchy 22 converts the request into a 
device-B local format and then requests the device-B driver 26 to provide the LOS state information. 
Accordingly, the device-B driver 26 provides the LOS state information based on the device-B local 
format to the DIA hierarchy 22. The DIA hierarchy 22 converts the LOS state information based on 
the device-B local format into the LOS state information based on the standardized common format 
and then provides the LOS state information based on the standardized common format to the 
higher-order application 20. As described above, the DIA hierarchy 22 arranged between the 
lower-order device drivers 24 and 26 provides a mutual interface based on the standardized rule. 
According to the change of the applications or devices, the verifications of the higher-order 
applications and the device drivers are not needed. 
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[0033] In order to provide the mutual interface based on the standardized rule between the 
higher-order application 20 and the lower-order device drivers 24 and 26, the DIA hierarchy 22 in 
accordance with the present invention reads materials from a DDCB (Device Driver Control Block) 
and accesses the lower-order device driver using functions defined by the standardized rule. The 
DDCB is defined to commonize the respective device drivers and then provides information 
associated with the existence of a corresponding function and the position of a corresponding 
function. 

[0034] In the embodiment of the present invention, only functions available in a corresponding 
device driver among functions of a function block defined and standardized in international 
organizations such as ITU/RFC (International Telecommunications Union/Request For Comments), 
etc. is defined in a function table. The present invention employs all function blocks defined in 
standardized documents made by international organizations for standardization such as ITU 
(International Telecommunications Union), IETE (Internet Engineering Task Force), ETSI 
(European Telecommunications Standardization Institute), ATM (Asynchronous Transfer Mode) 
forum, ADSL (Asymmetrical Digital Subscriber Line) forum, etc. In the embodiment of the present 
invention, only functions available in the corresponding device driver among functions of all 
function blocks defined by the international organizations for standardization are re-defined in the 
function table. 



[0035] 



In the embodiment of the present invention, the DIA hierarchy 22 uses device handler IDs 
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(identifiers) based on a standardized data format so that developers of higher-order applications 
easily control the devices. The device handler ID has the standardized data format according to the 
embodiment of the present invention and are unique identifiers corresponding to the respective 
devices. The DIA hierarchy 22 provides the device handler IDs to the higher-order application 20 
during the initialization of the corresponding device. The higher-order application 20 stores the 
device handler IDs and calls a corresponding device using a corresponding device handler ID where 
it is necessary to call the corresponding device. Accordingly, the DIA hierarchy 22 decides on the 
basis of the device handler ID whether some device driver should be called, and then calls a device 
driver according to the decision. 

[0036] Hereinafter, a detailed description will be given of the device handler IDs being the unique 
identifiers and a command control table generated and provided to the higher-order application 20 
by the DIA hierarchy 22 with reference to Figs. 5 to 8. Further, a corresponding event table and a 
profile of a corresponding device module mentioned in the embodiment of the present invention will 
be described in detail with reference to Figs. 5 to 8. 

[0037] Fig. 5 is a view illustrating a connection structure of a DCB (Device Control Block) after 
an application user calls an API "DiaJnitDevice" of the DIA hierarchy 22 for the sake of the device 
initialization. Fig. 6 is a view illustrating a final DCB in a level 1 initialization stage. Fig. 7 is a 
view illustrating a connection structure of a DCB when an HDLC (High-level Data Link Control) 
device having four ports corresponding to a level 2 is initialized. Fig. 8 is a view illustrating a 
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[0038] First, the device handler IDs will be described in detail. 

[0039] A device handler ID of a corresponding device generated by the DIA hierarchy 22 is 
represented, for example, as a "DCB handlerld[ 1.0.0]" shown in Fig. 5. The device handler ID is 
made up of three unsigned integers associated with a level 1, a level 2 and a channel, and has a . 
unique value within the system. The device handler ID is made up of xl .x2.x3 where xl , x2 or x3 
is an unsigned integer. The device handler ID is represented as "DCB handlerld[x 1 .x2.x3]". Here, 
xl is a value of the level 1 meaning a device ID, and x2 is a value of the level 2 meaning a logical 
or physical group number of a corresponding device, and x3 is a value of the channel meaning a 
channel number of a corresponding device or group. If values of x 1 , x2 and x3 are "0", it means that 
there is no corresponding level or channel. When the device is initialized, an integer value of xl 
sequentially increases from " 1 " as shown in Figs. 6 to 8. There cannot exist a handler having a value 
of the level 1, i.e., xl = "0". This means that the value of the level 1 is not initialized. 

[0040] As shown in Fig. 5, if the value of the level 1 is initialized, a DCB 32 containing elements 
called by a device is dynamically assigned on the basis of the standardized rule in accordance with 
the embodiment of the present invention. The elements include various pointers and function 
pointers for performing the standardized rule in the DIA hierarchy 22. When the value of the level 
1 is initialized, the elements of the DCB 32 include "*pHandler", "*fpInitDevice", 
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"♦fpOpenChannel", "*fpCloseChanner, "*fpRead", "*fpWrite", "*fpReset", "*pControlTable", 
"*pDDCB" "*pEventTable" and "*p Anchor". The "*pHandler" is a pointer for pointing a position 
of a given initialization profile when a device is initialized, and the "*fpInitDevice" is a function 
pointer used when a device is initialized. The "*fpOpenChannel" is a function pointer used when 
a channel is open. The "*fpCloseChannel" is a function pointer used when a channel is closed. The 
"*fpRead" is a function pointer used when data of an open channel is read. The "*fpWrite" is a 
function pointer used when data of the open channel is written. The "*fpReset" is a function pointer 
used when a device is reset. The "*pControlTable" is a pointer for pointing a position of a command 
control table. The "*pDDCB" is a pointer for pointing a position of a device driver control table 36. 
The "*pEventTable" is a pointer for pointing a position of an event table 38, The "*pAnchor" is a 
pointer for pointing a next level. 

[0041] After all devices are initialized, the DIA hierarchy 22 provides generated device handler 
IDs to the higher-order application 20. The higher-order application 20 initializes a corresponding 
device and then stores only a given device handler ID. If a device handler is called, the DIA 
hierarchy 22 receives the device handler ID, decides whether some device driver must be called, and 
calls a device driver according to the decision. 

[0042] Next, a standardized command control table being a function table will be described. 



[0043] The standardized command control table employs function blocks and elements associated 
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with a corresponding function block defined by international organizations for standardization such 
as ITU, IETE, ETSI, ATM forum, ADSL forum, etc. If there is an additional requirement, it can be 
optionally added to the standardized command control table. For example, the present inventor 
organized information relating to super high-speed communications as tables. The made tables are 
stored in a corresponding memory portion. Further, if necessary, another function can be optionally 
added. 

[0044] As shown in Fig. 5, the standardized command control table 34 is positioned in a memory • 
portion pointed by the pointer of "*pControlTable" of a corresponding DCB. A command ID of the 
command control table 34 is standardized and defined as a unique value. The command ID is 
mapped to the function pointer of "*fpCommandFn" corresponding to a command function. 

[0045] A structure of the command control table 34 according to the embodiment of the present 
invention is as follows. 

[0046] « Structure of standardized command control table » 
typedef enum 

{ 

DSDHCOMMANDIDSTART = 0x2000000 
D_SDH_SPI_COMMAND_ID_START = 0x2000100 

Page 13 of 36 



PATENT 
P56833 



D_SDH_SPI_SETALS, 
D_SDH_SPI_GET_ALS, 

D_SDH_COMMAND_ID_END 
} DIA COMMAND ID SDH E; 



[0047] In the above-described structure of the standardized command control table 34, a 
standardized command "typedef enum" such as "DIA_ COMMAND JD SDH^E" exists as 
"DIA_COMMAND^ID^PDH_E ,, ,"DIA_^COMMAND_ID^ATM_E , ' ) ^c. on a field basis. Various 
command functions can be arbitrarily added to the standardized command control table 34. The user 
of the higher-order application can arbitrarily call a corresponding device driver through the 
standardized command control table 34. Although a device driver is changed, a corresponding 
standardized command remains as it is. Only a function pointer is varied when the corresponding 
device driver carries out a corresponding command. The function pointer is provided to the DIA 
hierarchy 22 by the device driver when a device is initialized. The command is called through an 
API "Dia_Control" by the user of the higher-order application. When the user of the higher-order 
application calls the API "Dia^Control" through a specific control command, only a device driver 
positioned below the DIA hierarchy 22 is varied. 



[0048] Next, the device driver control table 36 according to the embodiment of the present 
invention will be described with reference to Fig. 5. In Fig. 5, the device driver control table 36 is 
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a table pointed by the pointer of "*pDDCB". The device driver control table 36 contains function 
pointers "*fp" for pointing positions of "InitLevel 1 "InitLevel2", "OpenChannel", "CloseChannel", 
a control table, an event table", etc., e.g., "*fpInitLevell", "*fpInitLevel2", "*fpOpenChannel", 
"♦fpCloseChannel", "*fpControlTable (not shown)", "*fpEventTable (not shown)", etc. Further, 
the device driver control table 36 contains information (not shown) indicating the number of 
initialization functions, the number of ports and the number of channels associated with a device. 
The device driver control table 36 is defined to commonize controls of the device drivers and 
corresponds to a DDCB (Device Driver Control Block) for providing information associated with 
the existence of a corresponding function and the position of a corresponding function. The device . 
driver control table 36 contains "*fpInitLevell", "*fpInitLevel2", u *fpOpenChannel", 
u *fpCloseChannel", "*fpControlTable (not shown)", "*fpEventTable (not shown)", etc. When a 
device is initialized, the device driver control table 36 being the DDCB is located by the pointer of 
"*pDDCB". The materials of "*fpInitLevell", "*fpInitLevel2", "*fpOpenChannel", 
"*fpCloseChannel", "*fpControlTable (not shown)", u *fpEventTable (not shown)", etc. are filled 
as information of the assigned DCB 32. 

[0049] Next, an event table associated with the embodiment of the present invention will be 
described. 



[0050] An event table 38 shown in Fig. 5 is a structure located at a position pointed by the pointer 
of "*pEventTable" of a corresponding DCB being generated only if necessary. When the event table 
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is not used, it is indicated as a null The event table 38 includes an event ID of "Eventld" and an 
event list structure pointer of "*pEventList" Each event list is a linked list as shown in Fig. 9. 
Accordingly, a plurality of places can be notified of one event and a call-back function of "Call-back 
Fn" can be called. The event table 38 initially includes the event ID of "Eventld" and the pointer 
of "*pEventList" is initially pointed as a null. When the user of the higher-order application 20 uses 
a corresponding event, the higher-order application 20 can be connected to a pointer of an event list 
structure using an API "DiaRegister". 

[0051J A structure of the event table 38 according to the embodiment of the present invention is 
as follows. 

[0052] « Structure of event table» 

typedef struct 

{ 

EXECFUNC pCallBackFunc; 
EXACTLYJNT32_T *pNextCallback; 
} DIA_EVENT_CONFIG_T; 

typedef struct 
{ 
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EXACTLY JJNIT32JT eventld; 
DIAEVENTCONFIGJT *pEventList; 
} DIA_EVENT_TABLE_T; 

[0053] A profile of a device module associated with the embodiment of the present invention will 
be described. 

[0054] An input argument needed when the function pointer of "*fpInitDevice" of a corresponding 
DCB 32 shown in Fig. 5 is carried out has a form of a structure pointer. In a special case, a structure 
of a corresponding device can be defined. However, in a conventional case, a common structure 
including a base address at the time of initializing a value of the level 1 , a group ID corresponding 
to the level 2 and a channel ID at the time of initializing a channel is used. 

[0055] A common structure of a profile of a device module according to the embodiment of the 
present invention is as follows. 

[0056] « Common structure of profile of device module» 

typedef struct 

{ 

EXACTLYJJNIT32JT baseAddressl; 
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EXACTLY_UNIT32_T numExtraBaseAddresses; 
EXACTLY_UNIT32_T *pExtraBaseAddresses; 
} DIABASEADDRT; 

typedef struct 
{ 

DIA BASE ADDR T baseAddress; 
EXACTLY_UNIT_32_T *pUserDefine; 
} DIA COMMON LEVEL 1 PROFILE T; 

typedef struct 
{ 

EXACTLY_INT32_T groupNo; 
EXACTLY_UNIT32_T *pUserDefine; 
} DIA_COMMON_LEVEL2_PROFILE_T; 

typedef struct 
{ 

EXACTLY INT32 T channelNo; 
EXACTLY_UNIT32_T *pUserDefine; 
} DIA_COMMON_CHANNEL_PROFILE_T; 
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[0057] Hereinafter, a detailed description of an operation according to the embodiment of the 
present invention is as follows. 

[0058] When the higher-order application 20 calls a function of a function block to be used, the 
DIA hierarchy 22 identifies the existence of a corresponding function from a function table using the 
DDCB having information indicating the existence and positions of corresponding function tables. 
If the corresponding function tables exist, the corresponding function is called. To call the function, 
the DIA hierarchy 22 informs the higher-order application 20 of a device handler ID when a 
corresponding device is initialized and then the higher-order application 20 accesses a lower-order 
device driver using the device handler ID. 

[0059] First, an operation at the time of initializing a device is as follows. 

[0060] When the user of the higher-order application 20 calls an API "Dia_InitDevice", the DIA 
hierarchy 22 dynamically assigns the DCB 32 containing pointers associated with each of function 
blocks {e.g. , a control table, an event table, etc. ) used by the higher-order application 20 through the 
DDCB having information indicating corresponding function tables. 

[0061] After the API "DiaJnitDevice" is called, a connection of the DCB will be described in 
detail with reference to Figs. 5 to 8. According to a basic flow form, an addition of a database 
structure will be described. 
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[0062J ( 1 ) Level 1 initialization 



[0063] A device to be initialized has a level 1, a level 2 and a channel. When the level 1 is 
initialized, the DCB 32 being a highest-order block of the device is dynamically assigned. 
Thereafter, the level 2 of the device is pointed by an anchor pointer of "*pAnchor" of the DCB 32 
associated with the level 1 . Since the number of devices used in each card is a known value, it is 
assumed that a highest-order database 40 is defined with a pointer of "*DCB" indicating a device 
ID shown in Fig. 5 as a global variable and the DCB 32. 

[0064] A form when the level 1 is initialized is the same as Fig. 5. Further, in a level 1 
initialization stage, a final DCB is shown in Fig. 6. Whenever the DCB 32 shown in Fig. 5 is 
generated, the DIA hierarchy 22 returns a unique device handler ID value of "DCB 
Handlerld[xl.x2.x3]" corresponding to each DCB 32 to the higher-order application 20 as shown 
in Fig. 6. That is, the DIA hierarchy 22 gives the device handler ID value of "DCB 
Handlerld[xl.x2.x3]" while sequentially increasing a value of xl from "1" according to an 
initialization sequence of the level 1 of a device. Referring to Fig. 6, a device handler ID value of 
an HDLC (High level Data Link Control) returns to "DCB Handlerld[ 1 .0.0]". A device handler ID 
value of a LAN (Local Area Network) returns to "DCB Handlerld[3.0.0]". A device handler ID 
value of a UTOPIA (Universal Test & Operations Physical layer Interface for ATM) returns to "DCB 
Handlerld[4.0.0r. 
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[0065] The higher-order application 20 should manage the returned device handler ID value of 
"DCB Handlerld[xl .x2.x3]". The user of the higher-order application 20 can call a corresponding 
function using the returned device handler ID value of "DCB Handlerld[xl .x2.x3]". Further, since 
the device handler ID corresponding to a device is given on the basis of the device initialization 
sequence, the user of the higher-order application 20 should identify any device corresponding to the 
returned device handler ID. For example, when there are three HDLC1, HDLC2 and HDLC3 
devices, the xl value of the HDLC3 device becomes "1" when the HDLC3 device is initialized. 

[0066] (2) Level 2 initialization 

[0067] The DIA hierarchy 22 can carry out the level 2 initialization after the level 1 initialization. 
At this time, used information includes information of the allowable number (the number of ports) 
in the level 2 associated with the DDCB (having a unique initialization function, and information 
relating to the number of ports or channels). For example, an anchor is assigned so that the level 2 
initialization can be carried out by referring to the number of ports associated with a corresponding 
device. Further, the DIA hierarchy 22 designates an address of the DCB 32 generated at an anchor 
of the level 1 so that the DCB 32 necessary for the level 2 can be referred to. 

[0068] Fig. 7 is a view illustrating a connection structure of a DCB when an HDLC device having 
four ports corresponding to a level 2 is initialized. Referring to Fig. 7, anchors of " Anchor 1", 
"Anchor2", "Anchor3" and "Anchor4" assigned to the four ports corresponds to device handler ID 
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values of "DCB Handlerldf 1.1.0]", "DCB Handlerld[ 1.2.0]", "DCB Handlerld[ 1.3.0]" and "DCB 
Handlerld[ 1 .4.0]", respectively. For example, if there are the four ports of "port 1 " "port2", "port3" 
and "port4", the anchors of "Anchor 1", "Anchor2", "Anchor3" and "Anchor4" are assigned to the 
four ports of "port 1" "port2", "port3" and "port4" respectively. The device handler ID values of 
"DCB HandlerId[L1.0]", "DCB Handlerld[ 1.2.0]", "DCB Handlerld[ 1.3.0]" and "DCB 
Handlerld[1.4.0]" can be given to the four ports of "portl", "port2", "port3" and "port4", 
respectively. 

[0069] (3) Channel initialization 

[0070] A DCB associated with a channel is generated only if necessary. Where the DCB is 
associated with only a channel irrespective of the level 2, an anchor of "Anchor 0" is connected to 
the DCB as shown in Fig. 8. 

[0071] In a connection structure for channel initialization as shown in Fig. 8 similar to Fig. 7, 
anchors identical with the number of channels are assigned and each anchor is connected to the 
DCB. At this time, a device handler ID value is returned, A port corresponding to the anchor of 
"Anchor 1" is associated with four channels of "channel 1", 'channel 2", "channel 3" and "channel 
4". When the channel of "channel 3" is open, "DCB Handlerld[2.1.1]" for the open channel of 
"channel 3" is returned according to an initialization sequence. The user of the higher-order 
application 20 should manage a corresponding channel and a device handler ID value mapped to the 
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[0072] After the device initialization, the higher-order application 20 calls a function of a function 
block using a device handler ID value of "DCB Handlerld[xl .x2.x3] being a standardized identifier. 
Accordingly, the DIA hierarchy 22 identifies the existence of a corresponding function from a 
function table of a corresponding device driver using a DDCB having information indicating 
positions of corresponding function tables. If a corresponding function exists, the function is called. 

[0073] Fig. 10 is a view illustrating a case where a device driver is changed (or replaced) in 
accordance with an embodiment of the present invention. 

[0074] Referring to Fig. 1 0, although a device driver A is changed to a device driver B by the DIA 
hierarchy 22, a device handler ID value of "DCB handlerld[ 1 .0.0] for a device HDLC is never varied. 
What is varied is that only a lower-order device driver and pointers (addresses) of the DCB 32 point 
new devices under control of the DIA hierarchy 22. Accordingly, the higher-order application 20 
can carry out the same functions although the lower-order device driver A is changed to the 
lower-order device driver B. 

[0075] Figs. 1 1 to 14 are views illustrating a comparison of operations in a conventional art and 
an embodiment of the present invention where a higher-order application or a lower-order device is 
changed. 
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[0076] Figs. 1 1 and 13 is views illustrating cases where a higher-order application is changed. 
Fig. 1 1 is a view illustrating a case where a higher-order application (program) is changed in a 
conventional art. Fig. 1 3 is a view illustrating a case where a higher-order application (program) is 
changed in accordance with an embodiment of the present invention. 

[0077] First, referring to Fig. 11, when the higher-order application A is changed to the 
higher-order application B in the conventional art, the higher-order application should be not only 
changed but also the lower-order device driver should be changed. The reason why the higher-order 
application and the lower-order device order should be changed is that structures and APIs associated 
with the higher-order applications A and B are different and then the lower-order device driver 
should provide changed forms of APIs that are requested. Accordingly, an operation of an addition, 
deletion or correction should be applied to a pre-existing lower-order device driver. Changed 
portions should be newly verified. Of course, the higher-order application B should be newly 
verified. 

[0078] In order to make up for a disadvantage of the conventional art shown in Fig. 1 1 , the DIA 
hierarchy 22 is arranged between a higher-order application hierarchy and a lower-order device 
driver hierarchy as shown in Fig. 13 in accordance with the embodiment of the present invention. 
If the DIA hierarchy 22 is arranged between the higher-order application hierarchy and the 
lower-order device driver hierarchy, the higher-order applications A and B can use the same control 
command of Control A, Control B and Control C based on a DIA's standardized rule, although the 
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higher-order applications A and B are changed. The higher-order application does not directly 
control the device driver, but indirectly controls the device driver through the DIA hierarchy 22 using 
the control commands, which are included in devices. Referring to Fig. 13, the control commands 
of Control A, Control B and Control C based on a standardized common format used by the 
higher-order applications A and B are individually converted into other control commands of Control 
A-l, Control B-l and Control C-l used in a device 1 by the DIA hierarchy 22. The control 
commands of Control A-l, Control B-l and Control C-l are provided to a device- 1 driver. 
Therefore, the higher-order application is not especially dependant upon the lower-order device 
driver, although it is changed. 

[0079] Figs. 12 and 14 are views illustrating a case where a higher-order application is not 
changed, but a lower-order device is changed. Fig. 12 is a view illustrating a case where a 
lower-order device is changed in a conventional art. Fig. 14 is a view illustrating a case where a 
lower-order device is changed in accordance with an embodiment of the present invention. 

[0080] First, referring to Fig. 12, where a higher-order application is not changed, but a 
lower-order device is changed in the conventional art, an API of the lower-order device driver is 
changed. Similarly, to use the changed API of the lower-order device driver, the higher-order 
application is changed. That is, a part of the higher-order application should be deleted or corrected 
or another part should be added to it. If so, the higher-order application as well as the changed 
lower-order device driver should be re-verified. 
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[0081] On the other hand, if the DIA hierarchy 22 is arranged between the higher-order application 
hierarchy and the lower-order device driver hierarchy as shown in Fig. 14 in accordance with the 
embodiment of the present invention, the higher-order application has not to be changed and only 
the lower-order device driver is changed on the basis of the DIA hierarchy 22. Accordingly, only 
the verification of the lower-order device driver is needed. Referring to Fig. 14, the control 
commands of Control A, Control B and Control C based on a standardized common format used by 
the higher-order application A are individually converted into other control commands of Control 
A-l, Control B-l and Control C-l included in a device 1 by the DLA hierarchy 22. The control 
commands of Control A- 1 , Control B- 1 and Control C- 1 are provided to a device- 1 driver. However, 
if the lower-order device driver is changed from a device- 1 driver to a device-2 driver, the device-2 
driver informs the DIA hierarchy 22 that control commands used in a device 2 are Control A-2, 
Control B-2 and Control C-2. Thereafter, the DIA hierarchy 22 individually converts the control 
commands of Control A, Control B and Control C based on the standardized common format used 
by the higher-order application A into other control commands of Control A-2, Control B-2 and 
Control C-2 used in a device 2. 

[0082] The present invention prevents a higher-order application hierarchy and a lower-order 
device driver hierarchy from directly accessing each other by arranging a DIA (Device Independent 
Access) hierarchy between the higher-order application hierarchy and the lower-order device driver 
hierarchy in a communication system. Accordingly, the higher-order application hierarchy and the 
lower-order device driver hierarchy can access the lower-order device driver hierarchy and the 
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higher-order application hierarchy via the DIA on the basis of the DIA's standardized rule, 
respectively. Because the higher-order application hierarchy and the lower-order device driver 
hierarchy accesses the lower-order device driver hierarchy and the higher-order application hierarchy 
on the basis of the DIA's standardized rule, respectively, a period of time required for the 
development of products, and costs of product development can be reduced, and efficiency of 
product development can be improved. 

[0083] Although the preferred embodiments of the present invention have been disclosed for 
illustrative purposes, those skilled in the art will appreciate that various modifications, additions and 
substitutions are possible, without departing from the scope of the invention. Therefore, the present 
invention is not limited to the above-described embodiments, but the present invention is defined 
by the claims, which follow along with their full scope of equivalents. 
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